feat: embed Coder agent chat in VS Code sidebar panel by ThomasK33 · Pull Request #844 · coder/vscode-coder

ThomasK33 · 2026-03-17T13:18:57Z

Summary

Adds a new Coder Chat webview panel that embeds the Coder agent chat UI directly inside VS Code, triggered via a deep link.

Deep link format

vscode://coder.coder-remote/openChat?url=<coderUrl>&token=<sessionToken>&agentId=<chatAgentId>

How it works

The /openChat URI handler calls setupDeployment() to authenticate, then opens the chat panel.
ChatPanelProvider renders a webview containing an iframe pointing at /agents/{id}/embed on the Coder server.
The embed page detects the user is signed out and sends postMessage({ type: "coder:vscode-ready" }) to the parent.
The webview relays this to the extension host, which replies with the session token.
The webview forwards { type: "coder:vscode-auth-bootstrap", payload: { token } } into the iframe.
The embed page calls API.setSessionToken(token), fetches user + permissions, and renders the authenticated chat UI.

Why not cookies?

Cookie-based auth (SameSite=None; Secure) does not work in VS Code webview iframes over HTTP. The setSessionToken approach uses header-based auth via axios, bypassing cookies and CSRF entirely.

Files changed

package.json — Added coderChat view container (panel, not activity bar) and coder.chatPanel webview view.
src/webviews/chat/chatPanelProvider.ts (new) — ChatPanelProvider class: postMessage relay, openChat(agentId), iframe HTML generation.
src/uri/uriHandler.ts — Added /openChat route and handleOpenChat() handler.
src/extension.ts — Creates and registers ChatPanelProvider, passes it to the URI handler.

Testing

Verified end-to-end against dev.coder.com: deep link → extension activation → postMessage auth → full chat UI rendered with multi-turn conversation and tool invocations.

This PR was authored with Coder Agents 🤖

Add a Coder Chat sidebar that opens via deep link: vscode://coder.coder-remote/openChat?url=...&token=...&agentId=... The chat panel embeds /agents/:agentId/embed in an iframe through a local reverse proxy (needed to work around VS Code webview sandbox restrictions). Auth is handled via postMessage — the iframe signals readiness, the extension sends the session token, and the iframe sets it as an axios header for all API requests. - chatPanelProvider.ts: WebviewViewProvider with EmbedProxy and postMessage relay for auth bootstrap - uriHandler.ts: /openChat route that reads agentId and opens the panel - extension.ts: registers the provider and wires it into the URI handler - package.json: coderChat view container (panel area, no activity bar icon) with coder.chatPanel webview view

The local reverse proxy was added to work around VS Code's webview sandbox blocking script execution in nested cross-origin iframes. Testing confirms the sandbox restriction does not apply when the iframe loads directly from the Coder server URL, so the proxy is unnecessary complexity. Auth continues to flow via postMessage+setSessionToken (no cookies, no CSRF, no proxy header injection).

- Remove unused getErrorHtml() (dead after proxy removal). - Extract renderView() to deduplicate resolveWebviewView/refresh. - Fix package.json indentation (extra nesting introduced in prior commit).

The existing /open deep link now optionally accepts an agentId query parameter. When present, the chat panel opens alongside the workspace. Old extensions silently ignore unknown query params, so this is fully backwards compatible — no error dialog, no version negotiation needed. The standalone /openChat route is kept for cases where no workspace context is needed (e.g. direct links from the agents page).

src/uri/uriHandler.ts

src/webviews/chat/chatPanelProvider.ts

EhabY · 2026-03-17T14:01:45Z

src/webviews/chat/chatPanelProvider.ts

+      const iframe = document.getElementById('chat-frame');
+      const status = document.getElementById('status');
+
+      iframe.addEventListener('load', () => {
+        iframe.style.display = 'block';
+        status.style.display = 'none';
+      });


This could be made more flexible so that even if messages arrive mid-run it wouldn't cause the status to always be displayed and never cleared (we could have some state tracking in this webview possibly). Anyway if this is unlikely or too much work then we can skip

I think that's a great idea for a follow-up, but it's not needed for this now.

This ties with the auth comment above, so maybe they should be tackled at the same time when needed!

Sure, though I'd argue that it's less a matter of when it's needed and more a matter of if it's needed.

src/webviews/chat/chatPanelProvider.ts

EhabY · 2026-03-17T17:01:50Z

src/uri/uriHandler.ts

 const routes: Readonly<Record<string, UriRouteHandler>> = {
 	"/open": handleOpen,
 	"/openDevContainer": handleOpenDevContainer,
+	"/openChat": handleOpenChat,


How can we trigger this one actually?

Via a direct deep link

I meant through the Coder UI, I could do /open but not /openChat, is it not implemented yet in coder/coder?

The updated deep links are not yet part of coder/coder. I want to get the extension changes merged first, in case the deep link needs to change.
I'm happy to remove the /openChat and just leave /open for now.

EhabY · 2026-03-17T17:03:10Z

src/webviews/chat/chatPanelProvider.ts

+		if (!this.agentId) {
+			webview.html = this.getNoAgentHtml();
+			return;
+		}
+
+		const coderUrl = this.client.getHost();
+		if (!coderUrl) {
+			webview.html = this.getNoAgentHtml();
+			return;
+		}


I keep getting the no agent HTML even though I have a chat running, am I doing something wrong 🤔 ?

src/extension.ts

commands.open() triggers vscode.openFolder with a remote authority, which reloads the window and wipes in-memory state. To survive this, handleOpen now saves the agentId to globalState before the reload. After the reload, activate() reads and clears it once the deployment is configured, then opens the chat panel. This follows the same set-and-clear pattern used by firstConnect.

No reason for it to be in a separate ctx.subscriptions.push block — chatPanelProvider is already created above.

ThomasK33 · 2026-03-18T07:29:21Z

Addressed in 5c933a8 — replaced the this.view! non-null assertion with an explicit throw new Error("renderView called before resolveWebviewView").

Worth noting: there are zero code paths in this PR that can actually trigger this throw — both callers (resolveWebviewView and refresh) guarantee this.view is set before calling renderView(). So this is technically dead code, but it's a reasonable defensive guard.

The /open route with an optional agentId param is the only deep link path for opening the chat panel. The standalone /openChat route and the chatPanelProvider dependency in the URI handler are no longer needed — the chat panel is opened from extension.ts after the remote-authority reload picks up the persisted agentId.

ThomasK33 marked this pull request as draft March 17, 2026 13:31

ThomasK33 added 7 commits March 17, 2026 15:17

refactor: remove dead code, fix duplication and indentation

aa5ab7f

- Remove unused getErrorHtml() (dead after proxy removal). - Extract renderView() to deduplicate resolveWebviewView/refresh. - Fix package.json indentation (extra nesting introduced in prior commit).

refactor: simplify chat panel rendering

51316bf

fix: pass chatPanelProvider mock to registerUriHandler in test

0cc8c02

fix: lint errors and formatting

02d44b2

ThomasK33 force-pushed the embed-chat-panel branch from a22e2c5 to 1e19564 Compare March 17, 2026 15:18

chore: format package.json

d9c8417

ThomasK33 marked this pull request as ready for review March 17, 2026 15:41

ThomasK33 requested a review from EhabY March 17, 2026 15:42

EhabY reviewed Mar 17, 2026

View reviewed changes

src/extension.ts Show resolved Hide resolved

EhabY assigned ThomasK33 Mar 17, 2026

ThomasK33 added 4 commits March 17, 2026 18:21

refactor: move registerUriHandler back to original location

8cc5b11

No reason for it to be in a separate ctx.subscriptions.push block — chatPanelProvider is already created above.

refactor: remove disposeInternals, use dispose directly

7852f5b

refactor: replace non-null assertion with explicit throw in renderView

5c933a8

ThomasK33 requested a review from EhabY March 18, 2026 10:45

Conversation

ThomasK33 commented Mar 17, 2026

Summary

Deep link format

How it works

Why not cookies?

Files changed

Testing

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ThomasK33 commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants